Technical Field
This disclosure relates generally to information security on network-connected appliances.
Background of the Related Art
Security threats are continually evolving. With the rapid growth of cutting-edge web applications and increased file sharing, activities that may have been considered harmless in the past could become potential openings for attackers. Traditional security means, such as anti-malware software and firewalls, have become easier to bypass. Thus, there is a significant need for more advanced, proactive threat protection that can help provide comprehensive security against new and emerging threats.
Network-connected, non-display devices (“appliances) are ubiquitous in many computing environments. For example, appliances built purposely for performing traditional middleware service oriented architecture (SOA) functions are prevalent across certain computer environments. SOA middleware appliances may simplify, help secure or accelerate XML and Web services deployments while extending an existing SOA infrastructure across an enterprise. The utilization of middleware-purposed hardware and a lightweight middleware stack can address the performance burden experienced by conventional software solutions. In addition, the appliance form-factor provides a secure, consumable packaging for implementing middleware SOA functions. One particular advantage that these types of devices provide is to offload processing from back-end systems. To this end, it is well-known to use such middleware devices to perform computationally-expensive processes related to network security. For example, network intrusion prevention system (IPS) appliances are designed to sit at the entry points to an enterprise network to protect business-critical assets, such as internal networks, servers, endpoints and applications, from malicious threats.
The use of Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS)-based encryption for network communications generally inhibits the ability to identify and mitigate threat traffic from within the network. It is now estimated that upwards of two-thirds or more of all business network traffic is conveyed over SSL/TLS. This means that organizations relying on network communications typically are unable to protect (from the network) the endpoints in their enterprise that may be susceptible to such threats. Indeed, the vast majority of SSL/TLS communications use only server authentication, i.e., the server is authenticated via the SSL/TLS protocols to the client, but the client is unauthenticated with respect to the server. This authentication asymmetry provides the opportunity for a process to interpose itself between client and server in such a way as to enable decryption of communications and inspection of its contents. Such a “man-in-the-middle” (MITM) process may be malicious, or it may be used for legitimate reasons, such as packet inspection (for threat detection).
Thus, it is known to provide a transparent (MITM) proxy between a client and a server that can be configured to create and manage two separate SSL/TLS sessions, one as the client to the target server, and another as a server to the initiating client. The intermediate proxy thus appears to the server as a client, and to the client as the intended server. Communications initiated from the client, and any responses received from the server, theoretically are then available for inspection and subsequent action by a SSL/TLS inspector.
When performing man-in-the-middle inspection of a SSL/TLS connection, support by the SSL/TLS inspector of TLS session resumption is an important requirement. Conventionally, and as well-known, TLS servers provide session resumption to clients (irrespective of the MITM) according to one of two (2) distinct methods, namely Session ID (RFC 4507), and Session Ticket (RFC 5077). Session ID was the first mechanism invented to speed up the SSL/TLS handshake and to enable session resumption. In Session ID, all of the session information is stored on the server side. Session ID session resumption has several disadvantages, the foremost being that it is a performance bottleneck due to the requirement of spending time and space to lookup a given session ID when there are a large number of cached sessions. Another major drawback of Session ID is that one session ID can only work on one server, which makes a deployment very hard to scale unless session caches are synchronized across the servers. To address Session ID deficiencies, Session Ticket was developed. Session Ticket is a mechanism that enables the TLS server to resume sessions and avoid keeping per-client session state. To this end, the TLS server encapsulates the session state into a ticket and forward it to the client. The ticket is signed by service provider. The client can subsequently resume a session using the obtained ticket. When the server later receives a ticket and determines it is signed by the service provider, it will honor every setting stored in the ticket. Session Ticket is widely used among web servers due to its scalability and less resource overhead on the server side.
To support both Session ID and Session Ticket in TLS inspection, caching at the inspector has been necessary. This is because there is no practical way to decrypt the session ticket, as the encryption mechanism is controlled by the application/service and not defined by the SSL/TLS specification. Maintaining session cache within the inspector, however, has several disadvantages, including poor scalability due to difficulty in distributing the session cache, limitations in session cache size due to storage and memory restrictions that can cause the proxy to run out of cache, CPU bounds that complicate cache loop-up time and that limit the type of hash algorithms that can be implemented, as well as vulnerability to denial-of-service attack by an attacker who could intentionally flush out entries in the session cache and thereby bypass inspection.
There remains a need to provide TLS session resumption in a TLS inspector that provides Session ID support but that overcomes these and related deficiencies in prior approaches.